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ELECTRONIC PROCUREMENT SYSTEM AND METHOD 
FOR TRADING AND EXCHANGE BY INSURERS, 
REINSURERS AND BROKERS OF RISKS AND CAPACITIES 

FIELD OF THE INVENTION 

The invention generally relates to a system and method for 
providing insurance andmore specifically to a system andmethod for facilitating 
reinsurance contracts. 

BACKGROUND OF THE INVENTION 

In 1999, the size of the global market for non-Ufe insurance was 
approximately $750 biUion. Reinsurance and insurance transactions typically are 
executed on a global basis. The reinsurance and insurance market is fragmented 
and has many intermediaries, buyers and sellers of risks and capacities that, even 
though the industry has regional hubs which operate as transaction aggregators, 
the path from underwriting and placing a risk to reinsuring that risk can be 
extremely complex, time consuming and expensive. 

Fig. 1 shows a typical present day transaction flow of a facultative 
offer as initiated by a direct insurer. The process of reinsuring a risk typically 
begins when a person or organization (requestor, R) calls a number, all or a mix 
of other direct insurers (for co-insurance support), reinsurers, or a reinsurance 
broker to request for reinsurance support (step 1). This group is often referred 
to as a panel I. A reinsurer is an msurance carrier that insures other insurance 
carriers against risks the insurer has assumed. Reinsurance is typically used to 
spread the risk originally assumed by the insurer. The greater the sum insured of 
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the risk, the greater the number of reinsurers or members in a panel is needed to 
fully allocate the risk. 

The co-insurers, reinsurance broker and/or reinsurers I work with 
the requestor R to clarify the details of the risk which the requestor R desires to 
5 reinsure. With the information provided by the requestor R, the parties in the 

panel I evaluate the terms and conditions offered by the requestor R and/or offer 
their own terms and conditions by which they would accept a share of the risk 
for reinsurance coverage. This process may require many exchanges between the 
g requestor R and die panel I before final terms are acceptable to all parties. Each 

Q 10 exchange or communication of information by the requestor R can be done 

Lij individually by telephone, facsimile, e-mail or other conventional 

j7i communication means, to the panel I previously selected (step 2). 

, Once received, each member of the panel I evaluates the offer 

transmitted from the requestor R. One or more members of the panel I can 
nj 1 5 immediately decide to either accept or decline the offer, but typically the panel 

members I contact the requestor R to request more information regarding the 
offer before accepting or declining (step 3). In step 4, following a request for 
information, the panel member I usually re-contacts the requestor R to obtain the 
necessary additional information regarding the offer, if available. Following 
20 information collection from either and/or the client and broker, the requestor R 

passes the information on to the information-requesting panel member I. 

In step 5, tiie panel members I express acceptance or declination 
of the cession. If panel membera I accept the offer, the ceding party (broker B 
or requestor R) gathers the acceptances from the panel members I by requesting 
25 for their acceptance codes and prepares provisional binders pertaining to the 

terms and conditions of the risk ceded. In step 6, tiie requestor R supplies each 
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accepting panel member I with a provisional binder reciting the particularities of 
the risk ceded. These provisional binders are typically manually generated and 
often mailed or faxed to the panel members I 60-90 days after the transaction 
was concluded as they need to be encoded and processed by the respective panel 
5 members' I company back rooms. 

Historically, the process illustrated in Fig. 3 requires days if not 
weeks to complete. Delays are often quite fi-equent when the requestors R are 
required to locate and provide the panel members I with sufficient information, 
more days for the panel members I to consider the information, and still more 

0 days for the insurers to re-contact the reinsurers and/or reinsurance brokers and 
communicate acceptance or declination. The mere transmittal of the various 
papers associated with the process shown in Fig. 3 can consume days. As time 
spent coordinating the placement and reinsurance of risk translates into money, 
the current process also is unnecessarily costly. 

5 One of the prime reasons that the current one-to-one process 

suffers significant time lags is due to communication gaps among parties. Also, 
various events which should occur upon the occurrence of other events, such as 
generation of a provisional binder upon acceptance, do not happen automatically. 
Further, the current process is shackled with time-consuming, labor-intensive 

) events, such as creating and transmitting offers, and creating and delivering 

provisional binders related to accepted offers to appropriate parties. 

In order to streamline the procurement process, more sophisticated 
insurance models have been considered and implemented with limited success. 
For example, some more forward direct insurers and reinsurers have tried a one- 

1 to-many exchange process. For the direct insurer that has established a one-to- 
many site, his site does not provide the breadth of choice that cedants require 
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when searching for insurers to underwrite their chents ' risks. In effect, such one- 
to-many sites simply operate as a one-way electronic mail facility and ultimately 
suffer from inherent "channel conflict." Other one-to-many sites currently in the 
market today also only offer "market specific" or "product specific" coverages. 
These coverages relate mostly to "commoditized" perils such as catastrophe 
covers and are North America-centric. There currently exists no truly neutral and 
open market place for insurers and reinsurers on a global basis. 

SUMMARY OF THE INVENTION 

The present invention overcomes the problems of the prior art by 
providing an electronic commerce system for automating transactions among 
direct insurers, insurance brokers, reinsurers and reinsurance brokers with a 
platform for conducting real-time, Internet-based trading of risks and reinsurance 
capacities. 

The electronic procurement system of the present invention allows 
users to trade, exchange, initiate and consummate insurance, co-insurance, 
reinsurance and retrocession transactions. The user are typically insurers, 
insurance brokers, reinsurers and reinsurance brokers. The system is a market 
place that aggregates buyers, sellers and intermediaries at a common, virtual 
information exchange. The system provides a market place that promotes cost 
and scale efficiency in a true many-to-many exchanges. 

In the preferred embodiment, the system is implemented as a 
Intemet website enabled by one or more servers. The users are required to 
register themselves as members, after which they can log onto the system in a 
secure manner. The system allows a cedant to develop and post a cession and 
then allows the cedant to select the other members that it wishes to respond to the 



cession. As the members log onto the system, they are informed of the cessions 
that they have been selected to evaluate, Altematively, the system provides the 
members with an e-mail notification informing them that a cession is awaiting 
their evaluation. If the receiving member has any questions conceming the 
cession, the question is immediately and directly forwarded to the cedant by 
private email/chat facility and the cedant can immediately respond either with 
the requested information or perhaps with a change to the cession. 

The system logs all of the recipient's responses to the cession such 
as acceptance or declination and forwards the responses to the cedant. If 
sufficient members of the parties have agreed to the cession, and the cedant 
executes the cession, the system automatically generates the required binders and 
forwards them to the accepting parties. 

The system includes groupware applications for facilitating 
collaborative efforts between the members of the exchange, typically insurance- 
related businesses. The system includes content that provides members with 
market and business intelligence to promote informed decision making. 
Interaction costs are reduced by the system as it reduces the time and effort 
searching for appropriate insuring and reinsuring parties and for quahfying of a 
risk for parties selected. Costs are further reduced since the system employs 
inexpensive, fast and convenient transaction communications. Over time, it is 
envisioned that intermediary costs will be reduced through lowering reinsurance 
and broker commissions, as a consequence of the reduced interaction cost. The 
system increases market efficiencies by providing greater access to market 
capacities. 
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Ofher features and advantages of the present invention will become 
apparent from the following description of the invention which refers to the 
accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention is described in detail below with reference to the 
following figures, throughout which similar reference characters denote 
corresponding features consistently, wherein: 

Fig. 1 illustrates the insurance or re-insurance process of the prior 

art; 

Fig. 2 shows the system of the present invention; and 

Fig. 3 is a flow chart illustrating the method of the present 

invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present invention is a system and a method for automating 
transactions among direct insurers, insurance brokers, reinsurers and reinsurance 
brokers. The system includes a platform for conducting real-time, Intemet-based 
trading of risks and reinsurance capacities. 

The physical elements for carrying out the invention are well 
known. Fig. 2 shows the generalized structural components of the present 
invention. Host computer 1 00 is linked with a plurality of anticipated users 1 1 0 
that access the host computer 100 through a computer network 120. In the 
preferred embodiment, the network 120 is the Internet, but can also be other 
networks such as a private Value Added Network (VAN). Alternatively, the 
users 110 can access the host computer using leased lines such as a Tl line. The 



present invention does not rely on the particular means by the users 110 connect 
to the host computer. The Intemet is the preferred network 120 for connecting 
to host computer as it has become ubiquitous throughout the world. 

In the preferred Intemet embodiment, the host computer 100 hosts 
a web site, a collection of text and image data and executable program data 
stored in an indexed database 130, which is accessible by the users 110 through 
the Intemet. The web site hosted by computer 100 has a conventional Intemet 
address which permits users 110 accessing the Intemet to locate the web site and 
view and/or execute programs associated therewith. Although only a single 
computer 100 has been illustrated as comprising host 100, it is appreciated by 
those skilled in the art that host 100 can be enabled by one or more computers 
and storage devices acting as data and appUcation servers. 

The users 110 access the Intemet typically with a personal 
computer electronically connected by telephone, or other conventional Intemet 
connectors, to an Intemet service provider (not shown). The Intemet service 
provider is connected to an Intemet hub (not shown), which is connected to other 
Intemet service providers and/or other hubs. Virtually any type of device can 
act as the user's interface 1 10 to host 100 such as a Personal Computer (PC), a 
workstation, a Personal Digital Assistant (PDA), a web enabled cellular 
telephone, a web enabled television or any other web enabled device for 
example. 

Prior to accessing the full range of services of the present invention 
offered on host computer web site 100, each user 110 registers with the 
administrator of the host computer 100. The administrator recognizes 
registrations from individual and company users. Registrants' applications may 
be verified manually, offline. Pending verification of the registrant's apphcation, 
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the applicant may access only the transactions ceded specifically to the user, as 
further described below. If verified and approved, a registrant's record is 
updated so that the registered user may enjoy full exchange privileges. The 
administrator may program the host computer 100 to allow registered users to 
5 receive e-mail notifications from the host computer 100 regarding exchange 

updates and newly posted offers. 

Once registered, a user 1 10 estabhshes communication with the 
host computer 100 via conventional Internet access. The user 110 estabhshes 
communication with the user's Internet service provider and provides the user's 
'=5! 10 user name and password, as is conventionally known. Upon successfully 

^■^ entering the appropriate user name and password combination, the Internet 

CI 

m service provider recognizes the user 11 0 as a valid user. Using a browser, such 

as Netscape™ or Microsoft Internet Explorer™, the user 1 1 0 accesses the web site 

i : 

of the host computer 100 by penetrating another level of network firewalls 
JiJ 1 5 foUowmg authentication by the host computer 1 00. Authentication by the host 

computer 100 may be obtained by any conventional means, such as successful 
entry of another user name-password combination. 

Once logged into the web site, the host computer 100 permits the 
user 1 10 to access authorized features and information of the site and engage in 

20 transactions with other users 110. The host computer administrator may establish 

parameters for a user's hierarchy within the system 100 to establish which users 
110 may access which portions the web site or engage in which administrative 
functions. The user may access the web site and transact business with other 
users so long as the user remains in good standing according to the web site 

25 rules. 
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Fig. 3 illustrates the method executed on system 100 for 
performing the main function of the present invention - facilitating insurance and 
re-insurance transactions. In step 300, one of the users 110 (the ceding party) 
logs onto the host computer 100 and creates a cession that he/she desires to be 
5 fulfilled. Again, the ceding party is typically an insurance broker, an individual 

or an insurance company and the cession represents a risk for which the ceding 
party desired insurance or reinsurance coverage. 

The process of creating a cession in step involves the user 110 
choosing the specific line of insurance for ceding or creating. Imbedded web site 

'55:1 

1 0 programing within host 1 00 provides users with templates of placement slips or 

W sheets, which users 110 complete with pertinent information on the risks 

CI 

Ul intended for cession. The templates provide conventional drop down menus for 

i=4 selecting attributes specific to particular lines of insurance coverages. Should no 

selectable menu item suit a user's needs, the user 110 may input details, 
q 1 5 including the types of the perils involved, with a template wizard. The template 

wizard is a software application that allows the user 1 1 0 to create a customized 
cession by prompting the user 1 10 for specific information about the risk and 
desired coverage that is then included in the cession generated by the wizard. 

Risks come m many forms, such as home, automotive, health, 
20 business and so forth. Each type of risk has attributes that may be unique or not 

applicable to other risks. Thus, each type of risk maybe described with a format 
that is different firom the formats of other risks. Accordingly, the host computer 
100 is configured to accept multiple formats for each type of cession. The web 
site-provided templates also permit users to include attachments in different 
25 formats, such as text files and image files. This allows users to provide 
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information to receiving parties about offered risks in a convenient and efficient 
manner. 

Once created, system 1 00 stores the submitted cession in a database 
for future access as described below. In step 305, the ceding party selects one 
or more potential insurers that he or she desires to review the cession. To 
facilitate choosing parties to form a panel of receiving parties, host 100 allows 
the cedent to search the host computer member data base by last name, first 
name, company name, country or other user-specified criteria. In a preferred 
embodiment, the cedent selects the recipients fi-om a drop down list of members 
provided on the web site. The member menus may list members by capacity, 
types of risks handled or other user-directed criteria. 

When the web site displays a member, a user 110 may obtain more 
information about the member by training the cursor over the member's name. 
Host 100 provides the user with the member's corresponding company 
information and photograph, if available. Users 110 may develop groups of 
"favorite" members for ready selection. Selecting a "favorite" group may be 
used as a shortcut for forming a panel to which a cession is posted, A user 110 
may form an entire panel of receiving parties simply by indicating, or clicking, 
on the name of a previously created "favorite" list. 

The host web site also permits users 1 10 to select panel members 
based on capacity market space. To this end, web site programing allows a user 
1 10 to post the user's capacities to advise others of same. Informing others of 
the user's capacity provides an opportunity for initiating business with other 
users 110 that otherwise may not interact. 

In step 310, host 100 notifies the selected recipients, the panel 
members, of the posting of the cession and permits these intended recipients to 



access the cession. In a preferred embodiment, the notification to the panel 
members is by e-mail. Security software in host 1 00 permits only panel members 
to access the stored cession and no other users 1 1 0 may access the cession, unless 
authorized by the cedant. Each panel member then evaluates the posted cession. 
Each panel member may respond by accepting the offer, declining the offer or 
requesting additional information about the offer. In step 3 1 5, the response or 
responses from the panel members are evaluated. 

If the particular response indicates that the panel member has 
declined the cession, the cedant is notified in step 320. If the panel member, 
after evaluating the cession, still requires more information, the panel member 
inputs the request for more information into host 1 00. The host 1 00 then, in step 
325, notifies the cedant of the request and passes on the request to the cedant. In 
step 330, the cedant provides, preferably through system 100, the additional 
information. The passage of the additional information can also be accomplished 
offline, for example, through a phone call between the cedant and the panel 
member. The cedant might also determine that the other panel members would 
benefit from the additional information. If this is the case, then system 100 
passes on the additional information to each of the panel members at the 
direction of the cedant. 

The host computer 100 permits the cedant to respond and engage 
in more confidential information exchanges with the panel members. For 
example, the cedant may respond with a private email or through a "chat room" 
function administered by the host computer. "Chat rooms" are well known, thus 
are not described herein. 

As a result of the additional information requested or other 
comments by the panel members, the cedant may choose or have to modify the 



terms of the cession. If this occurs (Yes, out of step 335) the panel members are 
requested to again evaluate the cession. If a panel member has already accepted 
the cession, that panel member's acceptance is voided and the panel member has 
to re-evaluate the cession and again provide a acceptance, a declination or a 
request for additional information. Similarly, over time, the specifics of a risk 
may change or additional specifics may become known. Accordingly, the host 
computer 100 permits the cedant to update a posted cession in order to 
incorporate the changes and additions. A cedant also may cancel or void a 
posted cession. 

Cessions that have been posted are either "firm" or "conditional." 
The host computer 100 allows a cedant to change any or all of the terms and 
conditions of a conditional cession. Each time the cedant changes a cession, the 
host computer 100 generates a message advising all of the panel members of the 
change. Once the cedant determines that all the terms and conditions are 
acceptable to the panel members, the cedant changes the status of the cession to 
"firm". While the offer (cession) is conditional, only the cedant knows the total 
amounts of acceptances that have been made and by which receiving party. In 
one embodiment, the cedant can keep track of the acceptances through the use 
of a "notepad" that the cedant may click on to record whatever information 
and/or details he/she wants regarding the offer. 

However, once the offer has been made firm, the cedant and the 
receiving parties may view the status, the percentage of acceptances and totals 
of everyone. This information is available on a specific screen [resented by host 
100 related to the cession. When the cedant executes the offer (as further 
described below), system 100 automatically computes all the acceptances and 
adds that to the cedant's gross retention. Should it fall below 100%, system 100 



-13- 

alerts the cedant liiat the offer is undersubscribed. The cedant then has the option 
to continue executing the Offer, which leads system 1 00 to automatically add the 
shortfall in acceptances to the cedant' s own gross retention. Alternatively, the 
cedant may choose to resend the offer to a new set of receiving parties by either 
5 sending them email notifications of the offer or by choosing members from the 

list of members maintained by system 100 as described above. 

If the panel member chooses to accept a share of the cession, the 
l„. panel member indicates its interest to the cedant and the percentage of acceptance 

:= J they wish to imdertake, together with an acceptance code. Host 1 00 registers the 

Gl 1 0 acceptance code which is unique to a panel member (for that cession) and serves 

Ul as the identifier for the panel member's company's transaction processing. A 

Q 

m single cession contract is almost always split among receiving parties, that is, 

r,4 each panel member that indicates acceptance to a cession accepts a percentage 

n of the total cession being offered. When the cedant is initially creating the 

y 1 5 cession (offer), part of the information required in the placement sheet that the 

hfe cedant fills out when posting an Offer are: the percentage of the offer that is 

being offered to a recipient, the percentage of minimum acceptance that the 
recipient can make, and the percentage of maximum acceptance for that member. 
Each panel member may opt to accept only some of the perils/conditions in a 
20 host of perils/conditions being offered in a single cession. Typically, this is 

accomplished through a communication between the cedant and the receiving 
party. One method by which this will be effected is through a "chat box". The 
receiving party, after viewing the terms and conditions posted by the cedant 
clicks on a "message" button on his/her screen presented by the host 100 and 
25 types ia a "message" with his/her desired or proposed terms and conditions of 

acceptance to the cedant. 
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Until the ceding party closes the offer, when the risk has been fully 
placed, panel members who have not accepted or declined the offer may continue 
to evaluate same. The ceding party notes acceptance codes transmitted by panel 
members that accept the risk. In step 340, it is determined whether the are any 
outstanding responses from panel members. The offer may be closed, at the 
discretion of the cedant, even if all of the panel members have not responded. If 
all of the panels members have responded or if the risk has been fully placed, the 
ceding party closes and executes the transaction in step 345. Executing the 
transaction means that the cedant has successfully placed the entire risk and that 
he now wishes to consummate the transaction. 

Before the cedant actually executes the cession, host computer web 
site programming permits the cedant to review the cession one final time. If the 
transaction is acceptable, the user executes the cession and the host computer 100 
generates a unique transaction code for the executed session. The host computer 
100 notifies all of the parties involved when a cession is executed. Thereafter, 
the placement is closed from further updates. 

Once the ceding party executes the transaction, host 100 
automatically generates the provisional binders required by the acceptances of 
the cession in step 350. These provisional binders are automatically distributed 
to the panel members that accepted the cession. Host computer 100 allows the 
parties to a transaction to view, print and download copies of the related 
provisional binders forprocessing within the party's company systems. Host 100 
further registers the executed tr^saction and archives all information related to 
the transaction, including communications related to the offer conducted through 
the web site. 

While logged into the present web site, users may engage in any of 



several options, posting and updating cessions; viewing posted cessions; 
"chatting" with counter parties; accepting, declining canceling and voiding 
cessions; forwarding and delegating cessions to other registered users within the 
users' organizations; viewing, printing and downloading provisional binders; 
viewing, printing and download reports; requesting special reports; and 
administering the users' accounts. 

In addition to the normal transaction process described above, the 
host web site 100 also provides a "pubKc space" where users 1 10 may post and 
view non-designated placements or cessions. In this manner, a user 110 may 
post a risk to the public space for all exchange members to view, without 
selecting particular members for evaluation of the cession. Host 100 further 
allows users 1 1 0 to view placements by line or by other conditions. For example, 
users may view placements by capacity, hazard, cedant or other criteria. 

When the cedant posts a cession to specific other users 110 as 
described above, the cedant always knows the identities of the receiving parties 
to whom a risk is ceded. On the other hand, the receiving parties may not know 
the identities of the other members who have been selected to evaluate a cession. 
Host 110 allows a receiving party to reveal it' s identity to other receiving parties. 
If a receiving party chooses not to reveal it's identity, host 100 identifies the 
receiving party as "anonymous." 

Should a cedant want to send a cession to a non-exchange member, 
the cedant may input a receiving party's email address to which the host 
computer sends an email notice to the receiving party with the cession URL. The 
non-exchange party accesses the cession by executing, or clicking, the given 
URL. Executing the URL launches the exchange registration page with which 
the non-exchange party must register before accessing the cession. 
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Should a cession be under-subscribed, based on the cedant-entered 
parameters during cession creation, the host computer 100 recognizes this 
condition and notifies the cedant of such. The cedant then may add more panel 
members to which the cession will be offered, as described above. A cedant also 
5 may override the system and execute the transaction. In response, the host 

computer re-calculates and increases the Cedant' s gross retention vis-a-vis the 
total acceptances by the panel members. 

Host system 1 00 also contains a feature known as a Renewal Alert* 
This feature provides an alert or reminder notification to a cedant that a 

10 transaction he/she previously executed is about to expire. Typically, insurance 

or reinsurance contracts have a term of a year. The cedant has the ability to 
choose the number of days, for example between 45-60 days, before the pohcy 
expires when the system 100 notifies the cedant of the expiring contract. At the 
time of the reminder or alert, the cedant will be presented with a copy of the 

1 5 transaction as in force. The cedant then has the ability to make changes and/or 

updates to the terms and conditions and generate a new cession (or a renewal) 
based on the expiring cession. The cedant can retain the same subscribing 
members, as well as adding or deleting members before ceding the new (or 
renewal) Offer to a panel. 

20 Although the present invention has been described in relation to 

particular embodiments thereof, many other variations and modifications and 
other uses will become apparent to those skilled in the art. The present invention 
is not limited by the specific disclosure herein, but only by the appended claims. 
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